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(57) ABSTRACT 

An electronic commerce system includes a broker computer 
system having a database of scrip representing a form of 
currency, a vendor computer system having a database 
containing products which may be exchanged for the scrip, 
a consumer computer system with which a user may initiate 
transactions with the scrip, and an agent computer system to 
which the consumer can delegate rights to perform actions 
with the scrip. To delegate actions on scrip, the delegator 
provides the delegatee with a delegation having a list of the 
delegated actions. In addition, the delegator determines a 
delegation scrip secret (DSS) and a delegation pass phrase 
(DPP) and securely passes these to the delegatee. The 
delegatee uses the DSS to authenticate itself to servers 
accepting the scrip and uses the DPP to encrypt the DSS 
while the scrip is stored by the delegatee. To perform an 
action with delegated scrip, the delegatee sends a request for 
the action to a server. The request includes the action, the 
scrip, the delegation, and a request stamp (RS) calculated 
using the DSS. The server validates the request by recalcu- 
lating the RS. When server provides the delegatee with new 
scrip having multiple delegations, the server encrypts the 
new DSS's for each delegation. The delegates uses the old 
DSS's to decrypt the DSS's for the new scrip. The delegatee 
stores the encrypted DSS for delegations for which the 
delegatee does not know the DSS. 

19 Claims, 4 Drawing Sheets 
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DELEGATION OF PERMISSIONS IN AN 
ELECTRONIC COMMERCE SYSTEM 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

This application is related to U.S. Pat. No. 5,802,497, 
entitled METHOD AND APPARATUS FOR CONDUCT- 
ING COMPUTERIZED COMMERCE, which issued on 
Sep. 1, 1998, and is hereby incorporated by reference herein. 

This application is also related to U.S. patent application 
Ser. No. 09/081,521, entitled METHOD FOR COMMUNI- 
CATING SECURE AND AUTHENTICATED TRANSAC- 
TIONS OVER AN NON-SECURE NETWORK SUBJECT 
TO EXPORT RESTRICTIONS, which was filed on May 19, 
1998, and is hereby incorporated by reference herein. 

This application is also related to U.S. patent application 
Ser. No. 09/273,240, entitled ENCRYPTING SECRETS IN 
A FILE FOR AN ELECTRONIC MICRO-COMMERCE 
SYSTEM, which was filed on Mar. 19, 1999, and is hereby 
incorporated by reference herein. 

This application is also related to U.S. patent application 
Ser. No. 09/273,102, entitled ANONYMOUS PURCHASES 
WHILE ALLOWING VERIFIABLE IDENTITIES FOR 
REFUNDS RETURNED ALONG THE PATHS TAKEN 
TO MAKE THE PURCHASES, which was filed on Mar. 
19,1999, and is hereby incorporated by reference herein. 

This application is also related to U.S. patent application 
Ser. No. 09/316,717, entitled METHOD AND SYSTEM 
FOR ENFORCING LICENSES ON AN OPEN 
NETWORK, which was filed on the same day as the present 
application, and is hereby incorporated by reference herein. 

BACKGROUND 

1. Field of the Invention 

This invention relates generally to an electronic com- 
merce system and more particularly to delegating permis- 
sions in the system. 

2. Background of the Invention 

With the advent of electronic forms of communication, 
including telegraph, telephone, radio, television, and more 
recently digital networks, it has become possible to conduct 
commerce electronically using digital computer systems. 
Many electronic fund transfer systems require a "trusted" 
third party between the vendor and consumer to authenticate 
the validity of the electronic funds. The requirement of a 
third party adds expense to every transaction because of the 
cost of extra communications and encryption. In addition, 
current electronic fund transfer networks, e.g., Western 
Union and Federal Reserve banks, typically require physi- 
cally secure communications media which is immune to 
"eavesdropping/' Such secure networks are generally not 
available to consumers at large. 

Alternative methods of electronic fund transactions 
involve establishing a long-term relationship between the 
vendor and consumer, either through a subscription service 
or by billing accounts as provided by credit card organiza- 
tions. These methods are efficient at handling transaction 
requests, assuming a reasonable authentication scheme. 
However, these methods require a prior effort to establish an 
"account" or other evidence of credit worthiness. For a large 
number of consumers, e.g. all potential users of a large 
network of computers like the Internet, setting up accounts 
and maintaining separate credit information with every 
vendor adds inconvenience and impediments to the 
consumers, and expense to the vendors. 
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In response to these needs, U.S. Pat. No. 5,802,497 (the 
'497 patent) describes a lightweight and secure protocol for 
electronic commerce over the Internet. The protocol is 
designed to support purchases costing less than a cent. The 
s system is based on decentralized validation of electronic 
cash at a vendor's server without much additional 
communication, expensive encryption, or off-line process- 
ing. 

Two innovations in the '497 patent are its use of brokers 

10 and scrip. Brokers take care of account management, billing, 
connection maintenance, and establishing accounts with 
vendors. Scrip is digital cash that is valid for only a specific 
vendor. The vendor locally validates the scrip to prevent 
consumer fraud, such as double spending. 

15 Every time a consumer visits a new vendor, the consumer 
must get scrip for that vendor from a broker. Scrip is held 
and manipulated by the consumer using an application 
called a "wallet." The wallet includes scrip with each request 
to purchase content and gets back change from the vendor 

20 with the returned content. The consumer's wallet may be 
stored and executed locally on the consumer's computer 
system or it may run on a remote server. 

Each piece of scrip has an associated customer secret. The 

25 consumer uses a hash including the customer secret to prove 
to the vendor that the consumer has the right to spend the 
scrip. Accordingly, the consumer's wallet must remember 
and protect the customer secret. The consumer has complete 
control of the scrip and no one else can do anything with it, 

30 as long as the consumer keeps the customer secret confi- 
dential. 

However, the consumer may wish to delegate the rights to 
perform specific actions with the scrip to one or more agents. 
For example, a consumer may be willing to trust a remote 

35 server to store its scrip, but the consumer may not be willing 
to give the remote server the right to spend the scrip. Yet, the 
consumer may want the server to refresh any scrip that is 
about to expire. Accordingly, there is a need for a way to 
delegate certain rights, permissions, and privileges to des- 

40 ignated agents for specific pieces of scrip without revealing 
the full customer secrets. 

SUMMARY OF THE INVENTION 

The above needs are met by a method and system for 
45 electronic commerce that uses a delegation scrip secret 
(DSS) to enable the delegation of permission to perform 
certain actions to agents. The system includes a broker 
computer system having a database of broker scrip, each 
broker scrip representing a form of electronic currency. The 
50 system also includes a vendor computer system having a 
database containing products which may be exchanged for 
the vendor scrip, the vendor computer system capable of 
providing vendor scrip. In addition, the system includes a 
consumer computer system with which a consumer may 
55 initiate transactions to obtain one or more of the products 
contained in the database of the vendor computer system. 
The system also includes an agent computer system to which 
the consumer can delegate rights to perform certain actions 
on the scrip. 

60 Each piece of scrip has a value, which, when it is a 
monetary value, may range from a few dollars to a few 
hundredths of a cent. In addition, each piece of scrip has a 
Customer ID from which a customer secret (CS) is derived. 
The broker and the vendor share and maintain a master 

65 customer secrets (MCS) table indexed by the Customer ID. 
When a broker (or vendor) issues scrip to the consumer, the 
broker hashes the Customer ID with the MCS specified in 
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ihe lable lo form the CS. A preferred embodiment of the (NDSS) function. The NDSS is calculated using the 

present invention uses the HMAC-MD5 algorithm for hash- delegation, the incoming scrip, the outgoing scrip, a nonce, 

ing when there is a distinguished value to use as the key, and and the DSS of the incoming scrip. The scrip, nonce, and 

the MD5 algorithm otherwise. The CS is sent to the con- delegation are returned to the delegatee with the new 

sumer with the associated piece of scrip. The consumer 5 encrypted DSS. Since the delegatee already knows the old 

holds the scrip and its associated CS in a database called a DSS for its delegations of the scrip used in the transaction, 

"wallet" and uses the CS to prove that the consumer has the the delegatee can decrypt the new DSS for those delegations, 

right to spend the associated scrip. If the delegatee does not know the DSS for a delegation of 

Adelegator, such as the consumer, delegates the rights to the scrip returned by the server, the delegatee stores the 

perform actions on scrip to a delegatee, such as an agent, by 10 encrypted DSS in the scrip file in a "deferred" format, along 

passing a list of the delegated actions to the delegatee along with information necessary to decrypt the DSS. When a 

with the scrip. For sake of efficiency, the absence of any party knowing the DSS for the scrip is activated, that party 

delegation represents the root delegation (i.e., the delegation can then decrypt the deferred DSS. 

of all rights). In addition, the delegation of certain actions _____ „ mwr ^ nn 

may implicitly delegate other actions. « BRIEF DESCRIPTION OF THE DRAWINGS 

The delegator also preferably derives a delegation scrip FIG. 1 is a top-level block diagram illustrating a comput- 

secret (DSS) from the CS for the scrip. The DSS for the root erized system for conducting electronic commerce; 

delegation is the CS. For other delegations, the DSS is FIG. 2 is a block diagram illustrating a computer system 

calculated as a hash of the new delegation with the old use(1 ^ ^ S y S t e m of FIG. 1; 

delegation scrip secret (i.e., the delegation secret owned by 20 „ ,. ' . . . ... 

« j * » \ .l i ^ i^oo • r Li i FIG. 3 is a flow diagram illustrating the operations of the 

the delegator) as the key. The DSS is preferably securely f & 6 r 

transmitted to the delegates. syslem 01 WU * A: 

When the delegator and delegatee share access to the "?^£g 3™ ^ ° perati ° nS 

stored delegation (for instance, when it is stored in the scrip epic e in ' ' 

file for the wallet), the DSS's must be encrypted by a method 25 FIG. 3B is a flow chart illustrating other operations 

that both the delegator and delegatee can decrypt. Therefore, depicted in FIG. 3; 

the delegator and delegatee must share a secret (called here FIG. 4 is a block diagram illustrating the data fields of a 

the delegation pass phrase or DPP) for the encryption. piece of scrip used in the system of FIG. 1; 

Preferably, the delegator derives the DPP from the delega- ^ piQ. 5 is a diagram illustrating transactions between a 

tor's own pass phrase and securely provides the delegatee delegator and a delegates in the electronic commerce sys- 

with the DPP. In one embodiment, the DPP is calculated as ( Cm; 

a hash of the delegator's pass phrase with the delegation and f i G 6 ^ a block diagram illustrating a scrip file held in 

a nonce. With this embodiment, the delegator does not need {hc waUel of a consumer compll ter system or in an agent 

to explicitly record the DPP for a^dejegatee. Alternatively, 35 computer system; and 

any agreed mechanism may be used to establish a shared ___ •.-*•«..■ . * a \ , a 

DPP between the delegator and delegatee. . .' 7 * a chart lllustratln S ^ s forusm « dele S a,ed 

_ , , ° , j . scrip in the electronic commerce system. 

The delegatee may either directly remember and use the 

DPP provided by the delegator, or preferably may encrypt DETAILED DESCRIPTION OF THE 

the DPP using a pass phrase of the delegatee's choice and 4Q PREFERRED EMBODIMENTS 

store it for eventual use. nn n . 

Alternatively, the delegator and delegates may store the , FIG - 1 shows a computerized system 100 for conducting 

scrip separately. At the minimum, for each piece of scrip, the elec,ronic f° mme ' ce ac ~ rdln S 10 principles of the 

delegator stores its encrypted DSS and the nonce used to inve » tl0n - ™ e s y s ' em 100 mckdes f bn *? s y s * m 110 ' a 

perform the encryption it. its file. In addition, the delegator 45 vendor s / e f m ™> a c " n j u 1 mer s y stem 130 > and an 

stores a delegation, encrypted DSS, nonce triple for each s ^ tem 150 interconnected by a communications network 
delegation of the scrip. Similarly, the delegatee stores the 

delegation, an encrypted DSS, and the nonce used to encrypt For clarity, the system 100 depicted in FIG. 1 shows only 

the DSS for each piece of scrip held by the delegatee and for single broker, vendor, consumer, and agent systems. In 

each sub-delegation of the scrip. 50 aclual P^ctice, any number of broker, vendor, consumer, 

To perform an action with a delegated piece of scrip, the J j[ a S cnt svstcms <» n bc interconnected by the network 
delegatee sends a message to a server, such as a broker or 

vendor, containing the action, the scrip, the delegation, and Th* broker 111 usin g * e broker s y stem m can be a bank > 

a request stamp (RS). The RS is preferably formed from a a credit provider, an Internet service provider, a telephone 

hash of the action, scrip, and delegation concatenated ss company, or any institution the consumer trusts to sell-scrip, 

together, with the DSS as the key. The server can determine The vendor system 120 is operated by a vendor 121. The 

the CS for the scrip, so the server is able to recreate the DSS vendor 121 provides products and content 150 of any type 

and, thus, recreate the RS and validate the delegatee. If the to consumers. 

delegatee validates, the server performs the requested action. A consumer 131 can use the consumer computer system 

Typically, the server will respond to the delegatee with 60 130 to "electronically"acquire the products 150 of the ven- 

new scrip. For each piece of returned scrip, the server returns dor 121. The network 140 can be public or private, such as, 

a new delegation for each delegation in the request, and a for example, the Internet, a switched telephone syslem, a 

new delegation for each ancestor delegation in the delega- satellite linked network, or another form of network, 

tion path of the incoming scrip (i.e., the scrip used in the A consumer 131 can delegate certain actions related to the 

request to the server). To avoid sending the delegation scrip 65 scrip to the agent 151 using the agent computer system 150. 

secrets for the new delegations in the clear, the server The agent 151 can perform the delegated actions in place of 

preferably encrypts the returned secrets using a new DSS the delegating consumer 131. For example, a consumer 131 
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may wish lo store the consumer's scrip on a remote server The consumer 131 desiring the products 150 provided by 

maintained by the agent 151. The consumer 131 may wish the vendor 121 can exchange 3040, 3045, 302 the broker 

to give the agent 151 the right to refresh any scrip that is scrip 320 for vendor scrip 330, and then exchange the 

about to expire, but not the right to spend the scrip. vendor scrip for products 150. If the purchase price of the 

Accordingly, the consumer 131 will delegate only the right s product 150 is less than the value of the vendor scrip 330, 

to refresh the scrip to the agent 151. ~ new vendor scrip can be issued for the balance as "change." 

A computer system 200 suitable for use as the broker, A ****** transaction type allows consumers 131 to ask 

vendor, consumer, and agent systems is shown in FIG. 2. vendors 121 and brokers 111 to refund scrip. 

The computer system 200 includes a central processing unit In an alternative embodiment shown in FIG. 3, FIG. 3A 

(CPU) 210, a memory 220, and an input/output interface 230 10 and FIG. 3B, the consumer 131 can establish an "account" 

connected to each other by a communications bus 240. The with the vendor 121 to acquire vendor scrip 330 directly, 

CPU 210, at the directioo of users 250, e.g. brokers, vendors, without the need of a third party broker as indicated in steps 

consumers, and/or agents, executes software programs for 3055 and 3060. Establishing an account means that an 

manipulating data. The programs and data can be stored in account data record is maintained in the vendor computer 

the memory 220 as a database (DB) 221. The DB 221 storing is svslem 120 * 

programs and data on the consumer computer system 130 is The consumer 131, in a transaction 304, submits the 

referred to as a "wallet." vendor scrip 330 to the vendor 121 in step 3045. The vendor 

The memory 220 can include volatile semiconductor 121 checks lhe slam P of me vendor ^"P 330 10 vtri ^ *■ 

memory as well as persistent storage media, such as disks. authenticity, and to validate the currency amount. Venn- 

The I/O interface 230 is for communicating data with the 20 cation also checks tne local database to determine whether 

network 140, the users 250, and other computer system the scrip is previously spent. Approval of the transaction 303 

peripheral equipment, such as printers, tapes, etc. results * ^ deliverv of the desired P roduct 150 to the 

nr« ntmr „ . ~ ftrt • | j • ,. tn consumer 131 in step 3050. In the transaction 304, change 

Ine computer system 200 is scaled in size to tunction as , f , i-m ■ *i_ * * 

4 , , , r , J - , can also be returned to the consumer 131 m the form of 

the broker, vendor, consumer, or agent system. For example, , ... , . ■ . ■ . c 

. _ i * _ \ tin t ul 25 vendor scrip having a value which is the amount of the 

when scaled as the consumer computer system 130, the r .... • . . L 

~ nrt . 11 i , over-payment, e.g., another data record communicated by 

computer system 200 can be a small personal computer . / i i A n \ a u a • a * -i u i *J 

k~~a ' „^^,ki^ tl« ™fi™,,«>t;™ „f t u a ™™, lf „ r the network 140. As desenbed m more detail below, the 

(PC), fixed or portable. Ine configurations oi the computer ... r.. / , . 

/ inn ■* , , r l ,l u i m a in consumer can delegate one or more of the actions illustrated 

system 200 suitable for use by the broker 111, vendor 121, . _ ^ A s . . « 

J . 4 + • * • i-» i ji in FIG. 3 to one or more agents 151. 

and agent 151 may include multiple processors and large ^ ...... 

database equipped with "fail-safe" features. The fail-safe 30 ™ e electronic signals which represent the scrip, and 

features ensure that the database 221 is securely maintained wh,( * are processed and communicated by the system 100, 

for long periods of time. are Ascribed with reference to FIG. 4. FIG. 4 is a block 

i-t^ t ™^ ~> * l c iL I/in diagram illustrating the data fields of a single piece of scrip 

FIG. 3 and FIG. 3A show an operation or the system 100 ... *• 

4 f , . y t Ct , . \. _ 400 according to one embodiment of the present invention, 

according to a preferred embodiment of the invention. The , c ~ aha • i • n * a • * a * c 1 a 

«i • * imi * u 35 The scrip 400 is logically separated into seven data fields, 

consumer 131 m step 3015 uses currency to purchase ^ ^ M ^ vendor fof ^ m 

electronic broker scrip 326 generated in step 3010 by the ^ c Value yalue scf ^ 

broker 111. Here, purchasing means that upon a validation of c . TP| « , , /11 . . 7. „ • • j Q „ t j fi ^, lU ^ A 

. ...... c in j . u > Scrip ID field 414 is the unique identifier of the scrip. The 

the authen icuy of the consumer 131 and the consumer s ^ fi ^ brokcr vendor 

currency 310 the broker system 110 generates signals m the 4 „ m ^ determine ^ cus(omer ^ } for ^ A 

form of data records. The signals in step 3020 are c ., ~ . rr*c u^irr *u ^ . 

.... . . 1 f A , r portion of the Customer ID field 416 forms the Customer ID 

communicated, via the network 140, to the consumer system r .... u m. c • a \a aid ^ - *■ 

1 1 a r . • .i_ n 4 r .i_ iia c *l partition number. The Expires field 418 gives the expiration 

Sns^meTsTemUO mem0ry ^ mc for thc SCrip 400 ' ^ c Pr0 P S field ™ hoIds c ^ t0rncr 

consumer system properties, such as the customer age, state of residence, etc. 

The currency 310 which is exchanged for scrip 320 can be 45 Finally> me Sump fie , d 422 holds a signature and is 

cash, check, credit card, bank ATM card, debit card, phone used tQ detect tampering ^ the 400. 

care I, or other itemsof value Tlie scrip 320 can also be freely [n ft ferred embodiment of me esent invention) the 

exchanged with coupons frequently used in promotional brokef m and vcndor m share & Mastcr Secret 

schemes. The coupons can be in the form of scrip. ^ indexed by lfae partition Qumber of ^ ^ 

The scrip is described in further detail below. In brief, the 50 tomer id field 416. Thus, the MCS table is as follows: 
scrip is stamped by the generator of the scrip. This means 
that the scrip carries information that is verifiable by only the 
originator. In addition, each script is uniquely identifiable. 
After a single use, the originator of the scrip can "invalidate 

it," meaning that the signals of the data record are no longer 55 
accepted for processing by the originating computer system. 

Preferably, the broker system 110 in step 3027 executes 
licensed software programs which generate vendor scrip 330 
for the consumer 131 as needed. In this case, the "value" of 

the license can be proportional to the amount of scrip that the 60 

licensee can generate. Alternatively, the broker 111, in a Both the partition numbers and the MCS are preferably 

similar transaction 303, exchanges currency 310 for bulk binary strings having lengths and values agreed to by the 

electronic vendor scrip 330 in step 3030 and 3035. The broker 111 and the vendor 121. 

vendor scrip 330 is generated in step 3025 by the vendor When the consumer 131 buys scrip 400 from the broker 

system 120. The scrip can have an expiration date so that the 65 111 (or receives scrip from a vendor 121), the broker 111 

issuer does not forever need to maintain data regarding the generates the CS for the scrip 400 by determining the 

issued scrip. partition number from the Customer ID field 416 and 





MCS Table: 


Partition Number 


Master Customer Secrets 


Pa 


MCS t 




MCS 2 




MCS, 
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looking up the corresponding MCS in the MCS table. Then, 400 was not altered. Next, the vendor 121 validates that the 

the broker 111 calculates the CS from a hash of the customer consumer 131 possesses the correct CS. If the stamp field 

ID with the MCS as: and CS validate, then the vendor 121 has a high degree of 

confidence that the scrip 400 was not altered and was 

cs-H(cusiomcr id, mcs), s received from someone knowing the CS. 

where H( ) denotes the hash function. In one embodiment, 0ncc thc vcndor 121 has validated the scrip 400 and 

the hash function used throughout the electronic commerce consumer 131, the vendor preferably provides the requested 

system is HMAC-MD5, described in H. Krawczyk, M. product to the consumer 131-Also, the vendor 121 may issue 

Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message scri P to the consumer 131 as change by using the techniques 

Authentication/' RFC 2104, February 1997, and R. Rivest, 10 described above. 

"The MD5 Message Digest Algorithm," RFC 1321, April For normal purchases, as described above, the knowledge 

1992, both of which are hereby incorporated by reference of secrets follows a defined trust relationship. It is acceptable 

herein. However, any suitably secure one-way hash function for brokers 111 to know the customer secrets for vendor 121 

can be substituted scr *P Decause th e brokers 111 are trustworthy. Vendors 121 

If this is the first piece of scrip purchased by the consumer 15 ^ &c customer secrets for scrip the vendors validate or 

131 from the broker 111, the CS is provided to the consumer P roduce - ^ consumers 131 know the customer secrets for 

131 via a secure channel and the consumer 131 stores the CS on[ y scn P thev own - 

in the wallet 221. A preferred secure channel is described in W*«n a consumer 131 delegates a set of actions for a 

U.S. patent application Ser. No. 09/081,521, entitled piece of scrip to an agent 151, the delegating consumer may 

METHOD FOR COMMUNICATING SECURE AND 20 not wish to give the agent 151 aU the secrets for the scrip in 

AUTHENTICATED TRANSACTIONS OVER AN NON- ordcr to maintain ultimate control of the scrip. Accordingly, 

SECURE NETWORK SUBJECT TO EXPORT the present invention allows the consumer 131 to delegate 

RESTRICTIONS, which was filed on May 19, 1998, and is actions without providing "stronger" scrip secrets than are 

hereby incorporated by reference herein. necessary for the agent 151 to perform the actions. 

If the consumer 131 has already received a CS from the 25 In description, a "delegation" is a set of delegated 
broker 111, the broker 111 uses the previously provided CS actions and > optionally, an expiration time for the delegation, 
(the old CS, or OCS) to transmit a new CS (NCS) to the A delegation is specific to a piece of scrip. Actions on scrip 
consumer 131 without requiring a secure channel. The that ma ? be ^legated include: spend, refresh the expiration 
broker 111 calculates the NCS using the Customer ID field lime > recover lost ^P* refund unused scri P> scn P t0 
416 and the corresponding MCS in the MCS table in the 30 olher currencies, subdivide scrip into multiple pieces, corn- 
same manner that the OCS was calculated. Then, the broker P lain about ? robl ™ P^chase, and any other useful actions. 
Ill calculates an encrypted NCS (ENCS) as follows: T° c delegation allows the agent 151, or other delegatee, to 

perform the delegated actions in place of the delegator. 

encs=ncs xor H(noncc, ocs), A preferred embodiment of the present invention repre- 

35 sents the set of actions in a delegation as a string listing the 

where "XOR" is the exclus,ve-or function and a nonce is a names of ^ del atcd actions . ^ root dc i cgauon is 

random, guaranteed unique string of arbitrary length. The defined ^ ^ m ^ of aU actions ^ Q0 expiration time . 

ENCS and the notice are passed to the consumer 131. However, for efficiency and convenience, the root delegation 

When the consumer 131 receives the ENCS and nonce, ^ implicitly defined by the absence of any delegation, 

the consumer 131 denves the NCS by performing the 4Q mereby removing the need t0 transmit a delegation in this 

calculation: case j n a dditi 0 n, ce rtain actions are preferably included in 

ncs=encs xor H(noncc, ocs). every delegation — such as refreshing scrip before it expires. 

These actions are always allowed and cannot be removed 

The consumer 131 preferably stores the NCS with the f rom a delegation. Once again, implicitly including certain 

corresponding scrip 400 in the wallet 221. Thus, the broker 45 actions with delegations removes the need to explicitly list 

111 communicates the value of the NCS to the consumer 131 and transmit an action which is always present, 

without actually transmitting the NCS in the clear. The An alternative embodiment of the present invention may 

consumer 131 uses the CS to prove ownership of, i.e., use alternate syntax to express delegations. One alternative 

possession of the right to spend, the scrip. embodiment support revocations in addition to delegations. 

In a preferred embodiment of the present invention, the 50 A revocation explicitly removes the right of the delegatee to 

consumer 131 requests product from the vendor 121 in the perform an action. For example, a delegator can delegate the 

context of the World Wide Web. However, the present fun se t of actions to a delegatee along with one or more 

invention can be used for purchases in any electronic revocations of actions in the set. The delegatee would be 

context. Accordingly, the request is preferably phrased as a aD l e to perform all of the actions in the set except for the 

uniform resource locator (URL) pointing to a location at a 55 revoked actions. 

vendor-controlled domain. FIG. 5 is a diagram illustrating the transactions between 

To spend scrip 400 for a product, the consumer 131 sends a delegator 510 and a delegatee 512 according to a preferred 

the vendor 121 a message in the form: embodiment of the present invention. In FIG. 5, the order of 

scrip request, H( BC rip request cs), lhe ^strated transactions can vary depending on the imple- 

60 mentation. Accordingly, the illustrated order should be con- 
where scrip is the vendor scrip 400 issued to the consumer, sidered as only one possible embodiment of the present 
the request is the URL specifying the requested product, and invention. 

H(scrip, request, CS) is a hash of the scrip, request, and the The delegator 510, may be, for example, a consumer 131, 

CS. Thus, the consumer 131 sends the scrip in the clear and the delegatee may be an agent 151. The delegator 510 

(unencrypted). 65 may also be an agent 151 or some other form of delegatee 

When the vendor 121 receives the scrip 400, the vendor with respect to another delegator higher up the delegation 

121 first validates the Stamp field 422 to ensure that the scrip path. To delegate a specific set of actions for a piece of scrip 
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400 from the delegator 510 to the delegates 512, the del- old delegation. The actions can be further sub-delegated. To 
egator 510 transmits 520 the scrip 400 to the delegates 512. sub-delegate the action D, the delegation and DSS is: 

In addition, the delegator 510 transmits 522 the delegation 
for the piece of scrip to the delegatec 512. The delegation C*. <=> d/a, onr, h(-a, c, d/a, d/et, dss(-a, c, d/a, d"))). 

delegates a set of actions that can be performed by the 5 _ _ . . . , , . , , . 

delegator 510 to the delegatee 512. To delegate a specific set fc If P^th of delegations and sub-delegaUons is different, 
of actions in a delegation, the delegator 510 appends the then DSS for f ^S*™ ^different. For example, 
names of the new sets of actions to the delegation owned by ° thcr delegations of action D and the associated DSS might 
the delegator. So, if the set of actions owned by the delegator 

510 is "X, Y, Z," and the delegator is delegating the actions 10 ^ D> . pss^^. 

"X, Z" to the delegatee 512, the delegator sends the delega- 
tion "X, Y, Z/X, Z" to the delegatee, where the "/" is the or 
delimiter between the delegations. 

The delegator 510 also transmits 524 a delegation scrip ( M B, c, D/D", dss(~b, c, D/D")). 

secret (DSS) to the delegatee 512. Any secure mechanism 15 

can be used to transmit the DSS. Although not shown at this In each of these examples, the path of ancestor delegations 
point in FIG. 5, the delegator 510 and delegatee 512 pref- ^at led to the delegation of D is different, thereby causing 
erably establish a delegation pass phrase (DPP), and use the delegation and DSS to be different. 

DPP to encrypt the DSS before it is transmitted. The The delegator 510 and delegates 512 preferably store the 
delegatee 512 uses the DSS to validate that it has the right 20 scri P and an y delegations of the scrip in a shared scrip file, 
to perform the delegated actions on the scrip. The calcula- The particulars of the scrip file are described in more detail 
tion of the DSS is defined as a recursive function: below. The basic method for protecting stored scrip is 

Let A, B, . . . , X, Y be sets of delegated actions, then: described in U.S. patent application Ser. No. 09/273,240, 

entitled ENCRYPTING SECRETS IN A FILE FOR AN 
DSS(a/ . . . /x/Y)-h(a/ . . . /X/Y, dss (a/ . . . /X)); 25 ELECTRONIC MICRO-COMMERCE SYSTEM, which 

was filed on Mar. 19, 1999, and is hereby incorporated by 
DSS(a/ . . . /x>h(a/ ... /X, dss(a/ . . . /w)) ; reference herein. In brief, application Ser. No. 09/273,240 

describes a method and system for protecting scrip stored in 
a file with a pass phrase. The user of the scrip (e.g., the 
dds(a)=h(a, cs); 30 consumer) supplies a pass phrase. The customer secrets for 

the scrip in the file are encrypted using the formula: 



DSSQ-CS, 



ECS«CS XOR H(nonce, pass phrase), 



where H(a, key) denotes the keyed hash function where "a" 
and "key" are any string or sequence of bits, and CS is the w here ECS is the encrypted CS. The ECS and the nonce are 
customer secret for the scrip. Thus, the DSS for the root 35 stored with each piece of scrip in the file. When the user 
delegation is the CS for the scrip. The DSS for a new provides the pass phrase, the hash is computed and XORed 
delegation is the hash of the delegation using the DSS for the with the ECS to get the original CS. 
ancestor delegation as a key. A preferred embodiment of the present invention encrypts 

As an example; suppose there are four possible actions on the DSS for a piece of scrip and any sub-delegations of the 
a piece of scrip: A, B, C, and D. The delegation for actions 40 SC rip using similar techniques. Preferably, each delegatee 
A, C, and D, and its DSS, is: 512 having a copy of the scrip should be able to decrypt its 

own delegation scrip secrets and any secrets that are derived 
from its delegations (i.e., from subsequent delegations made 



("A, C, D", DSS("A, C, D")), 



where "A, C, D" is a string containing the names of the 45 b M delegates 512). Each delegatee 512, however, should 

actions in the delegation and DSS("A, C, D") is the DSS for °e able to decrypt ancestor delegations or delegations 

the delegation that are no1 derived from tne delegatee 's delegation. The 

Fully expanded, the delegation and DSS for actions A, C, root delegator 510 is able to decrypt and encrypt every DSS. 

and D is* ~ Accordingly, the delegator 5 10 preferably derives the pass 

phrase for delegations from the dclegator's own pass phrase. 

("A, C, DD", H( 41 a, c, D", CS)) 50 According to this embodiment, the new delegated pass 

phrase (i.e., the delegatee's pass phrase) is calculated with a 

The CS is used in the hash because the CS is the DSS for the formula similar to the formula used to calculate the DSS. So: 
previous (i.e., root) delegation. Since each piece of scrip has 

a different CS, the delegation is only effective for the single dpp("a, c, d/d>h( m a, c, d/et, dpp("a, c, d-)), 
piece of scrip having this CS. 55 

To further sub-delegate actions A and D, the delegation where DPP is the delegated pass phrase for the parent 

and DSS is: delegation. Accordingly, the new DPP is the hash of the new 

delegation using the delegator* s pass phrase as the key. The 

(A, c, d/a, D", dss( m a, c, d/a, D")). pass phrase for the root delegation is preferably the pass 

60 phrase provided by the user. 

Fully expanded, the sub-delegation for actions A and D and -j^ DPP is preferably transmitted 526 to the delegatee 

the DSS is: 512 in a secure manner and the delegatee is responsible for 

~ /u a ~ remembering the pass phrase. For instance, the delegatee 

("A, C, D/A, D*\ H ("A, C, D/A, D , DSS( M A, C, D")))-("A, C, * £ . * c 9 \ 

d/a D" H(*A, c, d/a, D", h( 44 a, C, D", CS))). ma y slore tne DPP m aa encrypted form and decrypt it as 

65 necessary. The delegator 510 does not have to remember the 

As described above, the sub-delegated actions are appended DPP because the DPP can be derived using the delegation 

to the old delegated actions. The hash key is the DSS of the and the delegator's own pass phrase. In an alternate 
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embodiment, the pass phrase is chosen randomly and explic- 
itly stored with the scrip. The delegatee 512 preferably uses 
the DPP to encrypt the DSS for its delegation by using the 
equation: 

EDSS-DSS XOR H(noncc, DPP), 

where EDSS is the encrypted DSS, DSS is the DSS for the 
scrip, and DPP is the DPP received from the delegator 510. 
The EDSS is stored with the nonce and delegation in the 
scrip file. Since the delegates 512 knows the DPP, and can 
read the nonce and EDSS from the file, the delegates 512 can 
easily decrypt the EDSS. 

FIG. 6 is a block diagram illustrating a scrip file 600 that 
is preferably held by the wallet 221 on a consumer computer 
system 130 or held in an agent computer system 150. The 
scrip file 600 contains one or more entries 610A, 610B, 
610C, and each entry, such as entry 610A, holds a piece of 
scrip 400A. The scrip 400 has the fields illustrated in FIG, 
4. In addition, each entry 610 holds an ECS 612A for the 
scrip and the nonce 614Aused to encrypt the CS. Since the 
CS is the root delegation for the scrip 400A, the ECS 612A 
is also the EDSS for the root delegation. In addition, the 
entry 610 preferably holds a (delegation 61 6A, EDSS 618 A, 
nonce 620A) triple for its own delegation and for each 
sub -de legation of the scrip 400 A. 

FIG. 7 is a flowchart illustrating steps for using delegated 
scrip in the electronic commerce system 100. The agent 151 
or another delegatee, requests 710 that an action be per- 
formed on the scrip 400 by another party, such as a broker 
111 or a vendor 121. For example, the agent 151 may request 
that the broker 111 refresh scrip 400 that is about to expire. 
For convenience, the party receiving the request is referred 
to as a "server/* 

Assume that the agent 151 has received a sub -delegation 
for an action D on a piece of scrip, scrip 1 . Further assume 
that the total delegation path is "A, C, D/D". To request the 
action D on the scrip, scrip 1, the agent 151 sends a message 
to the server including the action, the scrip, the delegation 
authorizing the action, and a request stamp (RS). Thus, the 
message in this example is: 

D, script, "A, C, D/D", RS. 

The RS is preferably calculated as a hash of the action, scrip, 
and delegation concatenated together, with the DSS as a key. 
The RS in this example is: 

RS-H(D, script, "A, C, D/D", DSS("A, C, D/D")). 

When multiple pieces of scrip are used in a single action, the 
key for the RS hash is preferably the hash of all of the 
delegated scrip secrets. 

The server receiving the request (e.g., a broker 111 or 
vendor 121) validates 712 the request by recalculating the 
RS. The server knows the CS for the scrip because the server 
either initially issued the scrip or shares data with the party 
that did. Accordingly, the server can calculate the DSS from 
the CS. In this example, the DSS is calculated as follows: 

DSS("A, C, D")=H("A, C, D", CS); 

DSS("A, C, D/D'O-HCA, C D/D", DSS("A, C, D")). 

Once the server has the DSS for the scrip, the server 
recalculates the RS: 

RS-H("A, C, C/D", script, "A, C, D/D", DSS("A, C, D/D")). 

If the RS calculated by the server matches the RS provided 
by the agent 151, then the server knows that the agent knows 
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the DSS and that action D has been delegated to the agent 
151. Therefore, the server validates 712 the request. 

For almost all actions, the server replies 714 to the request 
with new scrip. The new scrip may be, for example, 

5 refreshed scrip having a later expiration date. When a server 
replies 714 to the request, the reply includes the delegation 
of the scrip, all ancestor delegations of the scrip, and a new 
DSS for each delegation. In other words, if the delegation for 
the request is "A, C, D/D", the reply includes the scrip and 

10 the specific DSS for each of the three delegations: "A, C, 
D/D"; "A, C, D"; and (the root delegation). 

The DSS for each of these delegations is returned securely 
as an EDSS using a New Delegated Scrip Secret (NDSS) 
function. The definition of NDSS includes dependencies on 

15 the specific pieces of incoming and outgoing scrip because 
there may be multiple pieces of scrip returned in one 
transaction and each has its own DSS. An EDSS is calcu- 
lated as follows: 

2Q EDSS-NDSS(delegation, incoming_scrip, outgoing__scrip, 

nonce)-H(nonce, DSS(delegatton, incoming_scrip)) XOR 
DSS (delegation, outgoing_scrip), 

where incoming_scrip is the piece or pieces of scrip 
received from the agent 151, outgoing_scrip is a specific 

25 piece of scrip being returned by the server, and XOR is the 
exclusive-or operator. When multiple pieces of incoming 
scrip are used, the key for the NDSS hash is not the DSS 
from a single piece of scrip, but instead is the MD5 hash of 
the delegated scrip secrets from all of the pieces of scrip. 

30 For the example of FIG. 7, suppose that SI is the 
incoming scrip and S2 is the ougoing_scrip. Three delega- 
tions are returned giving the delegation string, the nonce 
used in the NDSS calculation, and the encoded delegation 
secret: 

35 

EDSS_1 ("", noncel, NDSSC**', SI, S2, noncel)); 

EDSS__2 ( W A, C, D", nonce2, NDSS ("A, C, D'\ SI, S2, 
nonce2")); 

40 and 

EDSS_3=("A, C. D/D", nonce3, NDSS ("A, C. D/D", SI, S2, 
nonce3")), 

where EDSS_n are the returned encrypted delegations and 
45 noncel, nonce2, and nonce3 are the nonces for the each 
delegation. Calculating the NDSS is relatively efficient. The 
first new delegation requires only three hashes and is cal- 
culated as: 

- NDSS("'\ SI, S2, noncel)-H(noncel, DSS("", SI)) XOR DSS("'\ 

S2)-H(nonce 1, H("", CS1)) XOR H("", CS2), 

where CS1 is the CS for scripl and CS2 is the CS for scrip2. 

Once the root DSS functions for SI and S2 are calculated, 
the second new delegation requires only three additional 
S5 hashes: 

NDSSfA, C, D", SI, S2, nonce2)-H(nonce2, DSS( U A, C, D", 
SI)) XOR DSS( W A, C, D", S2)-H(noiicc2, HfA, C, D", 
DSS("", SI))) XOR H(" w , DSS(**A, C, D", S2)). 

60 Similarly, the final NDSS calculation also requires only 

three additional hashes. 
When the reply is received by the agent 151, the agent 

decodes 716 the EDSS to obtain the DSS for the new scrip. 

The agent 151 knows the scrip it used in the request, SI, and 
65 the delegation scrip secrets for its delegation and any of its 

sub-delegations. ITie reply returns the nonce, so the agent 

151 can calculate: 
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H(nonce, DSS(delegation, SI)). 

The agent 151 XORs ihis value with the EDSS value for its 
delegations. Since the two hash values cancel (because the 
values are equal and have been XOR'ed), the result of the 
XOR is the new DSS for the scrip. When the EDSS 618 is 
stored in the scrip file 600, the EDSS is said to be in 
"immediate" format — meaning it can be decrypted imme- 
diately by the agent 151. 

However, the agent 151 making the request is not able to 
decode the new delegation scrip secrets for the delegations 
of its ancestors on the delegation path because the agent does 
not know the original delegation scrip secrets for those 
delegations. For each of those delegations, the agent 151 
stores the nonce, the EDSS, and the originating scrip in the 
scrip file 600 in place of the EDSS 618 value. An EDSS 618 
represented in this manner is said to be in "deferred" format, 
since the decryption of the value is deferred to later. For 
efficiency, the originating scrip needs to be stored only once 
for multiple deferred EDSS values. 

When an ancestor of the delegatees 12 becomes active, it 
can then derive the deferred delegated scrip secrets. To do 
this deriving, the ancestor first decrypts the DSS for the old 
scrip, then it uses the old scrip's DSS to decode the new 
DSS. The ancestor can optionally decode only its own 
delegated scrip secrets or decode all of the deferred secrets 
for itself and any delegations derived from itself. If multiple 
pieces of scrip ate returned, the deferred secrets do not 
necessarily depend on a single piece of scrip but instead 
depend on all of the pieces of scrip that went into the action. 
Accordingly, the preferred deferred secret format gives all 
the scrip that it depends on and the scrip file preferably 
includes all of the scrip until the deferred secrets are 
decoded. 

If the delegatee 512 performs a series of actions between 
activations of its ancestor, then it preferably stores all of the 
scrip involved in the transactions in the scrip file 600. When 
an ancestor delegator (typically the consumer 131) is even- 
tually activated, it preferably resolves all of the deferred 
DSS in the chain of derived scrip. Once all of the derived 
scrip is consumed, the originating scrip is preferably deleted. 

In an alternative embodiment of the present invention, the 
scrip represents an "authentication" value in a light-weight 
security system, rather than a monetary value in a commerce 
system. In this embodiment, the consumer 131 purchases 
authentication scrip by presenting authentication credentials 
to a broker 111. The broker 111 verifies the credentials and, 
if appropriate, issues the authentication scrip to the con- 
sumer 131. 

Once the consumer 131 has the authentication scrip, the 
consumer can use it to access restricted content held by a 
vendor 121 in the same way a consumer uses monetary scrip 
to purchase content. The price of accessing restricted content 
is possession of scrip allowing access. The consumer 131 
can delegate the authentication scrip to a delegatee using the 
delegation tools described above. Different delegations of 55 
the scrip can allow access to different levels of restricted 
content. 

For example, assume content can have one of three 
increasing levels of security. Moreover, assume that content 
can only be accessed by a consumer 131 having a security 
clearance at least as high as the content. A consumer 131 
having authentication scrip proving the highest security 
clearance (i.e., the root delegation) can access all of the 
content. By using the delegation tools described above, the 
consumer 131 can delegate lower levels of clearance to 
delegatees, thereby allowing the delegatees to access only 
certain content. 
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Having described a preferred embodiment of the 
invention, it will now become apparent to those skilled in the 
art that other embodiments incorporating its concepts may 
be provided. It is felt therefore, that this invention should not 
be limited to the disclosed invention, but should be limited 
only by the spirit and scope of the appended claims. 
We claim: 

1. An electronic system, comprising: 
a delegator having rights to perform actions with scrip, 

and having a first delegation secret proving the rights 
held by the delegator, for delegating one or more rights 
to perform actions with the scrip; and 
a delegatee for receiving the delegation of the one or more 
rights to perform actions with the scrip from the 
delegator, the delegatee receiving a second delegation 
secret derived from the first delegation secret, a del- 
egation path from the delegator to the delegatee, a 
customer secret for the scrip, and the one or more rights 
delegated from the delegator to the delegatee, the 
second delegation secret proving the rights held by the 
delegatee. 

2. The electronic system of claim 1, wherein the first 
delegation secret is derived from the customer secret for the 
scrip and the rights to perform actions with the scrip held by 
the delegator. 

3. The electronic system of claim 1, wherein the delegator 
generates, and the delegatee receives, a delegation pass 
phrase for encrypting the second delegation secret. 

4. A method of using delegated scrip, comprising the steps 
of: 

receiving scrip, a set of delegated actions for the scrip, and 
an encrypted delegation scrip secret reflecting the set of 
delegated actions for the scrip; 
receiving a nonce; 

decrypting the encrypted delegation scrip secret with the 
nonce and a previously received delegation scrip secret; 
performing one of the actions in the set of delegated 

actions on the scrip; and 
proving the right to perform the action with the decrypted 
delegation scrip secret. 

5. The method of claim 4, wherein the step of performing 
one of the actions in the set of delegated actions on the scrip 
comprises the step of: 

sending a message comprising: 

the action to be performed on the scrip; 
the scrip; and 

the set of delegated actions for the scrip. 

6. The method of claim 5, wherein the step of proving the 
right to perform the action with the decrypted delegation 
scrip secret comprises the steps of: 

calculating a request stamp for the message with the 

decrypted delegation scrip secret; and 
sending the request stamp. 

7. The method of claim 6, wherein the step of calculating 
a request stamp for the message comprises the step of: 

calculating the request stamp from the action to be 
performed on the scrip, the scrip, the set of delegated 
actions for the scrip, and the decrypted delegation scrip 
secret. 

8. The method of claim 4, wherein computer instructions 
for performing the method steps are stored on a computer- 
readable medium. 

9. A method of delegating scrip, comprising the steps of: 
providing the scrip to a delegates; 
providing a delegation to the delegatee, the delegation 

granting the delegates the right to perform a set of 
actions with the scrip; and 
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providing a delegation scrip secret for the delegation to 
the delegatee, the delegation scrip secret enabling the 
delegatee to validate that the delegates has the 
delegation, the delegation scrip secret derived from a 
delegation path from a delegator to the delegates, a 
customer secret for the scrip, and the set of actions 
granted to the delegatee. 

10. The method of claim 9, wherein the step of providing 
the delegation to the delegatee comprises the steps of: 

appending a list of the set of actions granted to the 
delegatee with a delegation held by the delegator to 
form a new delegation; and 

providing the new delegation to the delegatee. 

U. The method of claim 9, further comprising the steps 

of: 

determining a delegation pass phrase; and 
securely providing the delegation pass phrase to the 
delegatee. 

12. The method of claim 9, wherein computer instructions 
for performing the method steps are stored on a computer- 
readable medium. 

13. A method of validating a request to perform an action 
with scrip, comprising the steps of: 

receiving the request to perform the action with the scrip, 

the request accompanied by a delegation and a first 

request stamp; 
determining a customer secret for the scrip; 
calculating a second request stamp from the customer 

secret, the delegation, and the scrip; 
determining whether the first request stamp matches the 

second request stamp; 
performing the requested action responsive to a positive 

determination that the first request stamp matches the 

second request stamp; 
providing new scrip responsive to the performance of the 

requested action; 
calculating at least one new delegation secret for the new 

scrip; 

securely transmitting the at least one new delegation 
secret; 

encrypting the at least one new delegation secret with the 
delegation, the scrip, a nonce, and the new scrip; and 
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transmitting the delegation, the nonce, and the encrypted 
new delegation secret. 

14. The method of claim 13, wherein the calculating step 
comprises the steps of: 

hashing the customer secret with the delegation to form a 

delegation secret; and 
hashing the delegation secret with the action, the scrip, 

and the delegation to form the second request stamp. 

15. The method of claim 13, wherein the delegation 
comprises a plurality of separate delegations and wherein 
the steps of providing new scrip and calculating at least one 
new delegation secret are performed for each of the plurality 
of separate delegations. 

16. The method of claim 13 wherein computer instruc- 
tions for performing the method steps are stored on a 
computer-readable medium. 

17. A memory for storing data for access by an application 
program being executed on a data processing system, com- 
prising: 

a data structure stored in the memory, the data structure 

holding information for use in an electronic commerce 

system, the information comprising: 

a scrip representing a unit of exchange in the electronic 
commerce system; 

a delegation for specifying an action that the applica- 
tion program can perform with the scrip; and 

an encrypted delegation scrip secret, the delegation 
scrip secret for validating the action specified by the 
delegation and derived from a delegation path from 
a delegator to a delegatee, a customer secret for the 
scrip, and the delegation. 

18. The memory of claim 17, wherein the information 
further comprises: 

a first nonce for decrypting the delegation scrip secret. 

19. The memory of claim 17, wherein the information 
further comprises: 

the customer secret for the scrip, wherein the customer 
secret is encrypted and wherein the decrypted customer 
secret represents a root delegation for the scrip; and 

a second nonce for decrypting the customer secret. 
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